Инструменты быстрого прототипирования / Хабр

Прототипы, как инструменты дизайна, находятся на подъёме, и вот почему. Я твёрдо верю, что прототипирование помогает нам в процессе создания качественных пользовательских интерфейсов. Мы работаем в мире богатых, обладающих динамикой интерфейсов пользователя как в сети, так и на наших устройствах. Интерфейсы, которые мы создаём, интерактивны, откликаются на воздействие пользователя и обладают эмоциями. Прототипы позволяют сформулировать чувства и функции дизайна так, как этого не могут сделать простые экранные формы. Но как выбрать лучший инструмент прототипирования для работы?

Создание эффективных прототипов
Для того чтобы оценить инструменты или техники прототипирования нам в первую очередь необходимо определить критерии эффективного прототипа. Лучшими являются те прототипы, которые вливаются в процесс дизайна. Мы хотим иметь возможность быстро переходить от набросков к интерактивному воплощению.
Эффективные прототипы быстры. Мы хотим использовать методики, которые помогают делать итерации короче. Этап создания прототипа не должно быть жестко закреплен в конце процесса дизайна. Включение создания прототипа в вашу ежедневную дизайнерскую работу способствует возникновению идей и бытрой проверке концепций.
Эффективные прототипы являются одноразовыми. Как и любой другой дизайн, предназначеный для реализации, мы создаём артефакт, предназначенный для того, чтобы донести идею до кого-то ещё (заинтересованного лица, разработчика, пользователя и т.д.). После того как дизайнерская идея была донесена, прототип реализации может быть отвергнут. Мы не должны переживать тяжёлое чувство, что создаём шедевр, который обязательно будет реализован, и безусловно не должны создавать прототип, работая на уровне кода.
Эффективные прототипы являются сфокусированными. Мы хотим выбирать интерактивные элементы нашего дизайна, которые действительно должны быть прототипированы. Ищите части вашего дизайна, которые сложны. Ищите паттерны взаимодействия, кторые давно известны в теории user experience. Ищите элементы взаимодействия, которые принесут пользу вашему продукту. Прототип, который продемонстрирует эти элементы, будет лучшим использованием вашего времени и энергии. […]
Выбор инструмента
Вместе с базовым набором, который инструмент прототипирования должен предоставлять нам для создания эффективного прототипа, мы рассмотрим, что подойдет нашей конкретной организации.
Первым делом давайте бросим взгляд на команду. Кто-нибудь из сотрудников умеет программировать? Является технолог дизайна членом нашей группы, занимающейся user experience? Есть ли у нас прочные отношения с инженерным отделом, кторый может помочь в создании прототипов? Что насчёт штатных разработчиков, кторые могут помочь? Определение наших технических возможностей укажет нам направление на программирование прототипа вручную или на использование основанного на рисовании ПО для прототипирования.
Как велика наша команда? Мы являемся командой по user experience, состоящей из одного человека, занимающегося одновременно и исследованиями, и рисованием скетчей и прототипированием? Или мы члены небольшой, сплоченой команды, которая может осуществить процесс создания готового прототипа менее чем за один день? Или мы являемся частью большой организации, и существует необходимость пробиваться в мутной воде корпортативной политики и различных точек зрения на наш прототип? Зачастую, чем больше команда, тем больше деталей прототипа (описания) потребуется.
Где находится люди, которые будут оценивать наш прототип? Находятся ли они в одном с нами офисе, заглядывая через плечо? Или они далеко? Находятся ли они в стране с тем-же самым часовым поясом? Положительный ответ на этот вопрос увеличивает вероятность обсуждения с помощью прототипа, так как он на все 100% описывает себя сам.
Является ли команда, занимающаяся user experience, частью команды по разработке, или привлечённой группой, занимающейся консалтингом? Если мы часть команды, то сильно ли мы интегрированы с инженерной группой, или мы совершенно отдельный департамент? Группе по user experience, которую привлекли со стороны, зачастую приходится отстаивать свой концепт дизайна немного больше.
Какой у нас бюджет на средство прототипирования? Как и с большинством ПО, границы предложений охватывают диапазон от бесплатного до дорогого. Лучшие решения как правило относятся к нижней части среднего ценового диапазона. Супер-дорогие решения (как в отношении времени, так и в отношении цены) как правило своего не стоят.
Насколько гибким должен быть наш инструмент прототипирования? Ориентируемся ли мы только лишь на одну платформу, например на веб? Или мы создаём дизайн для многих платформ, мобильной, терминалов, телевидения, бытовой электроники, интернета? Многие средства прототипирования создаются лишь для одного направления (чаще всего для веб-сайтов), поэтому мы либо должны выбрать что-то одно, что нам нравится, или остановиться на методах создания прототипов с помощью программирования.
Инструменты прототипирования
С учётом указанных критериев создан список инструментов прототипирования. […] Я надеюсь, что вместе мы сможем сформулировать подробные критерии выбора и варианты аспектов прототипирования. Этот список будет пересматриваться на основе обратной связи с сообществом.

* Выпущен, или добавлен в таблицу после опубликования поста в марте 2009
[1] За год
[2] За год
[3] Плюс $ 135 за Enterprise Architect
grumbler_chester: Таблица, содержащая список инструментов прототипирования, в оригинальном посте регулярно дополняется.

Школа разработчиков интерфейсов Яндекса снова открывает набор

До 31 января можно подать заявку в Школу разработчиков интерфейсов Яндекса. Обучение бесплатное, но входные требования довольно нетривиальные. Для приёма надо сдать тестовое задание. Чтобы его сделать, надо знать HTML, CSS и JavaScript и иметь хотя бы минимальный опыт разработки интерфейсов.

Кто такой разработчик интерфейсов? Это frontend developer, то есть тот, кто разрабатывает на HTML, CSS, JavaScript и вообще всём том, что отвечает за реализацию взаимодействия с пользователем. Обычно интерфейсы на этих технологиях мы делаем для десктопных и мобильных платформ. Но вообще проекты могут быть очень разные, например для телевизоров, как у одной из команд прошлого года.

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

Под катом чуть больше деталей про обучение и пример проекта студентов прошлого года.

Это шестая по счёту Школа разработки интерфейсов Яндекса. Обучение в Москве, нужно личное присутствие — дистанционных занятий нет, но все ключевые лекции снимаются на видео (ссылки в конце поста).

Занятия будут проходить в московском офисе Яндекса. Иногородним участникам мы оплатим проезд и проживание в хостеле.

Три занятия в неделю: по понедельникам и средам — с 19:00 до 21:00, по субботам — с 12:00 до 16:30, и если вы прошли на второй этап, то по субботам будет с 11:00 до 19:00.

Первый этап — это курс лекций и изолированных практических занятий. Примерно как в университете, только с очень чёткой направленностью на реальный мир. Лекции идут с 5 марта по 22 апреля.

Второй этап — практика. Вы объединяетесь с другими разработчиками в небольшие команды и работаете в режиме хакатона. Оценивается только готовый проект. Он разрабатывается с 23 апреля по 27 мая. Дизайнеры и проект-менеджеры команды — действующие сотрудники Яндекса, достаточно хорошие задания имеют шанс с минимальными доработками попасть в реальный продакшен, то есть у вас к выпуску может быть уже что-то значимое в портфолио.

Вопросы, связанные со Школой, можно задать в письме на адрес [email protected].

Программа первого этапа

Каждая тема — это блок теории, домашнее практическое задание и его разбор. Темы:

• Адаптивная вёрстка
• Работа с сенсорным пользовательским вводом
• Новые возможности JavaScript
• Использование Git и GitHub для работы в команде
• Мультимедиа
• Performance
• Модульное и интеграционное тестирование интерфейсов
• Инфраструктура
• Верхнеуровневая архитектура фронтэнда
• Node.js
• JavaScript и типизация
• Алгоритмы и структуры данных
• БЭМ

Пример задания второго этапа и впечатления участников

В прошлом году была Мобилизация, поэтому в хакатон-режим заходили сразу дизайнеры из Школы, менеджеры из Школы и разработчики интерфейсов. Одна из команд присматривалась к SmartTV на TizenOS (самая популярная платформа, установленная на телевизорах Samsung). Предположение у ребят было такое: во-первых, SmartTV в целом — это очень быстро растущий сегмент выхода в интернет (примерно по 40% роста в год). Во-вторых, там пока нет особой конкуренции, и надо «застолбить» площадку. В-третьих, нельзя просто взять и портировать туда мобильное приложение — и принципы ввода, и сценарии использования очень сильно отличаются.

Команда собралась из 3 разработчиков, менеджера и дизайнера. Дизайнер на первом этапе принёс вот такой проект:

Он включал исследования и аналитику, создание прототипов, тестирование на пользователях и план по развитию продукта. Это карта приложения со сценариями. Здесь показаны базисные пути использования приложения пользователем, которые нужны были для понимания проекта, как он должен работать.

Задачей команды было оживить все эти картинки, убедиться, что продукт нормально работает на конечной платформе, а пользователи не сходят с ума в попытках всё это использовать, и написать поддерживаемый код. То есть создать реальное приложение, которым можно пользоваться.

Вот какие нюансы работы были с точки зрения студентов:

Из-за CORS-ограничений невозможно реализовать прямой запрос к API из приложения, нужно было разработать собственный прокси-сервер, который позднее стал выполнять ещё и функцию кеш-сервера. Разработанный сервер представляет собой Node.js приложение, использующее веб-фреймворк Express. Данные нормализуются с помощью normalizr для дедупликации.

Мелкие сюрпризы были на каждом этапе. Например, на деплое команда неожиданно выяснила, что сервера сервиса Heroku размещены в Европе (а API Я.Музыки работает только в пределах РФ). И им понадобился VDS в России.

Фронтенд React + архитектура Redux. Под капотом TizenOS — старый хромиум. При работе ребята заметили, что не полностью поддерживается современная спецификация Flexbox, не поддерживается calc, focus-within, есть проблемы с viewport-единицами и производительностью css-анимаций. Вот еще один пример сюрприза, как его описывала сами участники: «сначала решение по управлению с пульта определяло навигируемые элементы по классу, который прописывается в конфиге. Все DOM-элементы с такими классами попадают в «поле зрения» библиотеки. При инициализации библиотека проходит все элементы с помощью querySelectorAll, а потом с помощью getBoundingClientRect определяет положение каждого элемента, сравнивает элементы и находит ближайших соседей. К этим элементам и будет происходить переключение. Для универсальной применимости библиотека совершает этот цикл при каждом переключении, что, конечно же, неэффективно, если у нас на странице не поменялось расположение элементов. Это (и много ненужных апдейтов компонентов) вызвало проблемы с производительностью на телевизоре. Провели декомпозицию компонентов, пересмотрели движение данных и устранили часть лишних апдейтов».

«Дома — это вообще другой сценарий, вечеринки, караоке. Выделили проблемы. Напилили много идей на будущее, которые не стали сразу реализовывать, — например, управление приложением на ТВ с телефона. Режим караоке не реализован. Режим вечеринки не реализован — это когда каждый подключился со своим девайсом, все накидали треки и все тащатся, то есть не переключаются между аккаунтами и не лезут друг другу на стены Вконтакте.

Реализовали приложение под Tizen, сделали крепкий базис. Это подключение аккаунта, проигрывание музыки, плюс тянем все плей-листы юзера и так далее. До последнего спорили, что важнее: напилить фич или сделать так, чтобы всё без вопросов работало. Выбрали второе, потому что до последнего не были уверены в том, что при раскатывании на телевизоры всех моделей всё это будет нормально работать. Беспокоились за тормоза на старых ТВ, за запуск на всей линейке Tizen.

Работали в трекере, были ежедневные встречи. Учитывали, что кому интересно, и такие задачи раздавали. Делали друг другу code review, плюс помогали кураторы из Яндекса. Расписание у всех разное было. Кто-то совмещал с работой/учёбой, кто-то мог больше времени уделять проекту. Подстраивались друг под друга. Когда могли, работали в переговорках Яндекса совместно, когда-то удалённо. Встречи проводили и очные, и по скайпу. Использовали чатик в Телеграмме.

У нас была возможность использовать лабораторию Яндекса и провести полноценный тест нашего приложения на посторонних пользователях. По-моему, этот момент всем очень понравился. Было интересно понаблюдать, поспрашивать. На реальном примере мы могли наблюдать, как какие-то очевидные для нас интерфейсные вещи были не такими очевидными для пользователя.

За месяц с нуля пытались выстроить процесс. Если бы поработали ещё месяц — встало бы на стабильные рельсы. Мы одновременно пилили и новый проект, и изучали платформу, и строили процессы в команде».

Егор Свертков, проект-менеджер

«Разработке я учился дома. Начиналось как хобби — делал простые приложения по туториалам и тестовые задания на вакансии, но на работу не устраивался. Увидел вступительное задание в ШРИ и решил попробовать. Задание делал долго и отправил за 10 минут до окончания приёма. А через месяц пришёл ответ — приезжай в Москву.

В ШРИ очень быстро прогрессируешь. Когда вокруг 20 с лишним разработчиков, всегда найдётся тот, кто знает ответ на твой вопрос. И если дома я бы доходил до решения несколько часов, то в ШРИ его можно узнать за 5 минут.»

Родников Дмитрий, разработчик интерфейсов в баннерной системе, выпускник ШРИ 2017.

«Мы были очень ограничены по времени при разработке приложения. А хотелось сделать много и хорошо. Поэтому для меня весь второй этап прошёл в режиме хакатона. Мы погрузились полностью в проект и весь месяц жили буквально только им.

Нам помогали кураторы, но они никогда не говорили нам, как надо сделать, а только подталкивали к правильному решению».

Яна Зольникова, разработчик интерфейсов главной страницы, выпускница ШРИ-2017

Даже на команде из 4 человек нужно было делать нормальное документирование. Документирование ui-компонентов ребята вели с помощью Styleguidist. В каждом компоненте прописывали PropTypes — какие свойства он принимает, какого типа и какие из них являются обязательными. Часть компонентов сопровождали примерами использования. В результате у них получилась библиотека ui-компонентов. Это позволило им разделить роли: один верстает компоненты, другой настраивает движение данных между ними. А также позволило каждому разработчику в команде знать, какие есть готовые компоненты и как их использовать.

Разделение такое: команда договорилась, что каждый разработчик будет создавать новую ветку для каждой фичи, открывать pull request и, после ревью других участников команды, сливать её в dev.

В первый день работы над проектом студенты завели канал в Тelegram, в котором вели всё обсуждение. Часть команды работала удалённо, часть — в офисе Яндекса. Поэтому участники регулярно отписывались о завершённых задачах и оповещали о том, что будут делать дальше. На разных этапах проекта они объединялись в группы и решали конкретную задачу. Парное программирование помогало быстро найти проблемы и перенять опыт друг друга.

Вся работа была разбита на 4 спринта:

• 1-й спринт — меню, страницы, навигация, знакомство с апи;
• 2-й спринт — плеер, кеш-сервер, доработки в навигации;
• 3-й спринт — подключение реальных данных, работа с выводом подборок по 3, навигация по клавишам, доработки в плеере, вёрстка лендинга;
• 4-й спринт — оптимизация работы приложения, правка багов, обработка ошибок, обработка отдельных сценариев, тесты.

Ещё пара рассказов про обучение

«В ШРИ я попал спонтанно — заинтересовали тестовые задания. На них ушло где-то четыре ночи. Честно говоря, отправляя результаты, я ни на что особо не рассчитывал — просто хотелось получить отзыв. Но через пару недель пришло письмо, что я принят. Школа дала мне в первую очередь практический опыт. Я вообще не очень воспринимаю теорию: мне можно тысячу раз рассказать, как это работает, но пока я не увижу всё сам, я не пойму. Хороший разработчик интерфейсов должен не просто воплощать макеты в коде, но и видеть за проектом продукт, участвовать в создании концепции вместе с менеджером и дизайнером. Для этого нужно уметь находить с людьми общий язык — этому ШРИ тоже учит».

Тамерлан Локьяев, разработчик интерфейсов в Яндекс.Маркете, выпускник ШРИ-2017

«Я окончил физфак Пермского государственного университета. Программированием меня увлёк сокурсник, который начал изучать C#. Помню, что мне захотелось сделать свой сайт — я занимался фотографией. После вуза я какое-то время работал тестировщиком медицинского ПО, а потом перешёл в IT-компанию: сначала был верстальщиком, потом разработчиком интерфейсов. Сейчас работаю в Яндексе, сюда меня позвали после ШРИ. На мой взгляд, разработчик интерфейсов должен быть разносторонним человеком, который разбирается и в алгоритмах, и в дизайне. Нужно иметь собственное чувство прекрасного — приятно, когда ты сам внутренне согласен с происходящим, а не просто принимаешь как есть то, что приносят дизайнеры. Не стоит увлекаться фреймворками и готовыми библиотеками. Нужно понимать язык, на котором пишешь, тогда он не будет для тебя чёрным ящиком».

Максим Лыков, разработчик интерфейсов видеопоиска, выпускник ШРИ-2017

Ещё раз ссылки

Универсальный GUI / Хабр

Здравствуйте! Меня зовут Халитов Кирилл, я аспирант из МГУДТ (Московский государственный университет дизайна и технологии (МГУДТ) ). В моей диссертации возникла задача упростить процесс создания интерфейса для локального и веб-приложения и в итоге получился сабж.

Введение

В настоящее время любая современная мониторинговая система включает в себя прикладное программное обеспечение (ПО) для визуализации данных. Как правило, запуск этого ПО предполагает наличие рекомендуемой операционной системы (ОС), в большинстве своих случаев ОС компании Microsoft. Однако сейчас наблюдается тенденция использования кроссплатформенных средств для разработки ПО. В результате этого появляется возможность запуска готового программного продукта на разных ОС, включая и мобильные ОС.

Кроме того, в связи с бурным распространением интернета популярным направлением разработки ПО стала разработка веб-приложений или веб-сервисов. Веб-приложение является полезным дополнением к клиентской прикладной программе (приложению). Обычно веб-приложение даёт возможность удалённого использования мониторинговой системы. Это означает, что пользователь не привязан к месту расположения аппаратной части мониторинговой системы и может использовать её из любой точки мира, где есть рекомендуемое интернет-соединение. Важно заметить, что разработка веб-приложений в значительной степени отличается от разработки клиентских приложений и это в свою очередь создаёт некоторые проблемы. В частности, это проблема создания универсального графического интерфейса пользователя (GUI). Чтобы клиентское приложение и веб-приложение были реализованы в едином графическом стиле, необходимо приложить достаточно усилий как разработчику интерфейса клиентского приложения, так и разработчику интерфейса веб-приложения. В конечном счёте величина усилий одного или другого разработчика будет зависеть от того, интерфейс какого приложения будет задавать общий стиль.

Современные способы построения интерфейсов

Рассмотрим наиболее популярные в настоящий момент способы построения интерфейсов клиентских приложений на языке C++, как наиболее используемом для разработки ПО, для ОС Microsoft Windows (MS Windows) и ОС Linux. Главным средством разработки ПО для MS Windows является MS Visual Studio [1]. Эта интегрированная среда разработки (IDE) позволяет разрабатывать ПО на разных языках программирования, но основными языками, конечно, являются C++ и C#. Для разработки интерфейса приложения имеются два основных средства — Windows Forms (WinForms) и Windows Presentation Foundation (WPF). Большая часть существующих приложений для MS Windows разработана с использованием WinForms, однако с появлением более современных версий ОС (MS Windows 7, 8), система WPF становится более популярной. Кроме того, последние версии MS Visual Studio позволяют использовать язык разметки HTML5 для построения интерфейсов, близких по стилю к нативным веб-приложениям. Однако стоит заметить, что коммерческая лицензия MS Visual Studio является платной, как и лицензия MS Windows, что несомненно является недостатком для низкобюджетных проектах.

Если говорить о низкобюджетных проектах, то тут наиболее подходящим вариантом является ОС Linux. Помимо того, что большинство дистрибутивов этой ОС являются абсолютно бесплатными, в том числе и для коммерческого использования, также имеется ряд бесплатных средств для разработки качественного ПО для ОС Linux. Самым распространённым средством для разработки ПО на языке С++ является кроссплатформенный инструментарий Qt [2]. Важно подчеркнуть, что Qt позволяет разрабатывать приложения не только для ОС Linux, но и для MS Windows, Mac OS X, Android и других UNIX-подобных ОС. Разработчики Qt предлагают как бесплатную для коммерческого использования, так и платную лицензию с дополнительными возможностями. Но исходя из современной практики разработки ПО с помощью этого инструментария, бесплатной лицензии оказывается больше чем достаточно.

Если проводить аналогию с MS Visual Studio, то в Qt мы имеем IDE Qt Creator. Здесь альтернативой WinForms являются так называемые виджеты (Qt Widgets), а альтернатива для WPF — Qt Quick. Также в Qt Creator имеется возможность создания интерфейсов на основе HTML5. Но наиболее интересным модулем инструментария является встраиваемый веб-движок WebKit, который лежит в основе всех современных веб-браузеров. Подобный модуль имеется и в MS Visual Studio, но он имеет ряд ограничений, и тем более нас больше интересуют низкобюджетные средства, которые позволяют уменьшить издержки при создания программного продукта. Веб-движок — это ядро браузера, он отвечает за правильное отображения веб-страниц. Модуль Qt WebKit позволяет создавать интерфейс клиентского приложения с использованием техники разработки интерфейсов веб-приложений. В основе создания интерфейса веб-приложения лежит устоявшийся стек технологий. Он включает язык разметки HTML (HTML 4, 5), каскадные таблицы стилей (CSS 2, 3) и скриптовый язык JavaScript с богатым выбором дополнительных библиотек (каркасов). Отдельного внимания заслуживает тот факт, что скорость появления новых полезных каркасов для языка JavaScript стремительно растёт, а это делает разработку, насыщенных функционалом приложений, более быстрой и удобной.

Теперь решение проблемы создания универсального GUI лежит на поверхности, но это только на первый взгляд.

Традиционный способ: Qt WebKit + Qt-костыли

Рассмотрим традиционный способ создания универсального GUI с помощью модуля Qt WebKit на примере модуля визуализации данных системы акустического мониторинга, разрабатываемой в рамках кандидатской диссертационной работы [3]. Под системой акустического мониторинга подразумевается система, включающая аппаратную и программную части. Аппаратная часть системы состоит из сенсорной сети акустических датчиков, данные с которых обрабатываются на микроконтроллере и отправляются по какому-либо интерфейсу (UART, IEEE 802.X и др.) на персональный компьютер (ПК). Программная часть состоит из набора прикладных программ, работающих как на локальном ПК (клиентское ПО), так и на удалённом сервере (серверное ПО).

Традиционный метод подразумевает использование межпроцессного

Рис. 1. Традиционный метод реализации универсального GUI

взаимодействия по средствам встроенного механизма Qt. Здесь подразумевается взаимодействие между основной логикой клиентского приложения, изображённой на рис.1 как Обработчик данных, и GUI-элементом. Одним из недостатков такого подхода является то, что код для реализации GUI на языке JavaScript будет иметь специфические функции, которые будут актуальны только для клиентского Qt-приложения. Для серверного приложения, отвечающего за GUI, нужен будет другой, специфичный для серверной реализации, код. Например, в случае использования PHP-скрипта для реализации основной логики серверного приложения, понадобится реализация межпроцессного взаимодействия с помощью какой-либо другой технологии (AJAX или WebSocket). Отсюда следует ещё один недостаток, а именно использование дополнительного языка программирования для реализации основной логики серверного приложения и разработка нового алгоритма межпроцессного взаимодействия.

Более интересный подход: Qt WebKit + WebSocket

Для решения этих проблем предлагается новый метод, основанный на использования упомянутой выше технологии WebSocket. Суть метода заключается в том, чтобы унифицировать метод межпроцессного взаимодействия между основной логикой приложения и GUI, как на клиентской стороне, так и на серверной. В этом случае появляется возможность использования JavaScript кода для реализации универсального для обеих сторон GUI.

Рис. 2. Новый метод реализации универсального GUI

На рис. 2. видно, что теперь для межпроцессного взаимодействия, как для клиентской, так и для серверной части используется технология WebSocket. То есть теперь мы имеем один универсальный JavaScript код для разных приложений. В этом случае необходимым условием является серверное приложение, основная логика которого реализована с помощью Qt, на не совсем привычном для веб-разработчиков, языке C++. С одной стороны такой подход к реализации серверного приложения усложняет задачу для узкоспециализированного веб-разработчика. Но с другой стороны мы имеем универсальные части кода, которые позволяют нам сэкономить время на дублировании одних и тех по смыслу алгоритмов на разных языках. Важно также подчеркнуть, что для использования технологии WebSocket необходима дополнительная библиотека, которая имеется в интернете в свободном доступе или включается по умолчанию в более поздние версии Qt.

Рис. 3. Локальное (справа) и серверное (слева) приложения, запущенные на ОС Ubuntu 14.04

На рис. 3 приведён пример реализации нового метода создания универсального GUI для ОС Ubuntu 14.04. Как видно на рисунке, в конечном итоге мы получаем универсальный интерфейс, как для локального приложения, запущенного в качестве исполняемого файла ОС, так и для серверного приложения, запущенного в современном веб-браузере. Так как для разработки ПО используются кроссплатформенные инструменты, это позволяет говорить о простой переносимости программного продукта на другие ОС в будущем.

Список литературы

1. Qt Documentation [Электронный ресурс]. Режим доступа: qt-project.org/doc
2. Visual Studio Library [Электронный ресурс]. Режим доступа: msdn.microsoft.com/en-us/library/vstudio
3. Молодые учёные – развитию текстильно-промышленного кластера (ПОИСК — 2014): сборник материалов межвузовской научно-технической конференции аспирантов и студентов с международным участием. Ч. 2. – Иваново: Иванов. гос. политехн. Ун-т, 2014. — С. 25 [Электронный ресурс]. Режим доступа: ti.ivgpu.com/poisk/file/part_2.pdf

P.S. Единственное, что на картинке бросается в глаза — это разные шрифты, но мне, честно говоря, тогда было не до них.

P.P.S. Можно ли запатентовать этот способ, чтобы на защите было чем козырнуть кроме свидетельства о регистрации ПО?

Игровой интерфейс и с чем его едят / Хабр

Всем привет! Данная статья — об игровых интерфейсах и порядку работы с ними. Она предназначена в первую очередь для тех, кто работает в игровой индустрии и в том или ином виде влияет на разработку интерфейса, но при этом сам не является UI/UX специалистом. Проект-менеджеры, продюсеры, геймдизайнеры, программисты, работающие с GUI, художники — я писал этот текст, думая о вас, ребята.

Вступительное слово. В своей практике я не раз сталкивался с тем, что разработкой и проектированием игровых интерфейсов занимаются люди, напрямую к этой области не относящиеся. Скажу больше, часто это люди, для которых обязанности, связанные с интерфейсом, являются дополнительным и нежелательным обременением. Чаще всего это связка геймдизайнер+художник, в которой геймдизайнер продумывает функционал и разметку экранов, а художник добросовестно старается “сделать красиво”. При этом зачастую ни тот, ни другой не имеют опыта работы с интерфейсами, не задумываются о юзабилити, пользовательских сценариях или единообразии элементов и в целом не понимают, как организовать процесс работы с интерфейсом, чтобы получить гарантированно хороший результат. И это происходит не по вине художников или геймдизайнеров, просто сама ниша игровых интерфейсов очень специфическая и узкая, информации по работе с ними очень мало, и людям банально негде набраться опыта, не с чего начать. Я хотел бы поделиться своим опытом и наблюдениями в этой сфере и предложить некую структуру, чек-лист, с которым можно сверяться при разработке игрового интерфейса на (вашем) проекте.

Пара слов о себе: работу в геймдеве я начал в 2011 году как flash- и web дизайнер. C 2013 работаю исключительно как дизайнер интерфейсов на игровых проектах, в основном мобильных. За это время я поработал в офисах как небольших стартапов, так и в крупных, устоявшихся компаниях; попробовал себя в качестве фрилансера-удаленщика и приходящего “эксперта”. Всего я поучаствовал в создании примерно двух десятков игр разного масштаба и качества, из которых около дюжины дожили до релиза и лежат в маркете. Если кому интересны конкретные тайтлы — пишите в личку.

И давайте договоримся сразу: то, что написано ниже — ни в коем случае не истина в последней инстанции. Мой опыт ограничен. Если вы считаете, что где-то я написал ерунду (или знаете, как сделать что-то лучше) — пожалуйста, свяжитесь со мной или опишите свое видение в комментариях.

Окей, теперь к сути. Давайте для начала окинем всю последовательность предлагаемых мною шагов разом, а затем я постараюсь объяснить, зачем нужен каждый из них и какие грабли вы рискуете собрать, пропустив или недооценив каждый из шагов.

1) Определение структуры и главных функциональных частей интерфейса.

2) Прототипирование ключевых экранов в виде схем.

3) Сброка и тестирование прототипа. Поиск стилистики и внешнего вида.

4) Отрисовка экранов, составление UI kit’а. Документация.

5) Внедрение в игровой движок, приемка и контроль качества.

6) Добавление интерфейсных анимаций.

7) Аналитика результатов.

Пойдем по порядку.

Шаг первый. Определение структуры и главных функциональных частей интерфейса.

Разработка интерфейса (в идеале) начинается после того, как сформирован дизайн-документ, описывающий базовый функционал проекта. Исходя из него, игра разбивается на логические части (к примеру, боевая сессия, глобальная карта, клановые интерфейсы и т.д.), которые, в свою очередь, дробятся на конкретные экраны. Затем команда, включающая в себя всех заинтересованных, набивается в переговорку и проходится по каждой части проекта, в дискуссионной форме стараясь ответить на вопрос “что именно там должно быть?”. В результате таких дискуссий формируются ТЗ для первых мокапов, которые затем попадают в руки UX-специалистов.

В процессе накидывания этих первичных мокапов будут материализовываться “правила”, по которым строится интерфейс на данном конкретном проекте. Как осуществляется навигация? Где будут располагаться кнопки? Сколько текста понадобится и какого примерно размера он будет? Нужны ли тултипы и иные всплывающие элементы и если да, то где и в каком формате?

На выходе вы должны получить генеральную схему экранов проекта, по возможности минимизировав при этом количество “белых пятен” на ней. Выглядит это как-то так:

На что тут следует обращать внимание:

• На связи между экранами.
• На функционал (удобно ли делать то, для чего экран нужен).
• На размеры и расположение основных элементов.

Хочу сконцентрировать ваше внимание на одной важной, на мой взгляд, мысли: геймдизайн должен значительно опережать графический дизайн. На этапе, когда детальных описаний экранов либо нет вообще, либо когда они есть, но только для одного-двух экранов, не надо начинать работать с интерфейсом, по крайней мере не на чистовую — используйте заглушки. В противном случае вы потеряете массу времени и денег на переделки. Помните, что перерисовывать макеты в заглушечном формате в разы проще и быстрее, чем переделывать уже «финализированный» интерфейс, не говоря уже о собранном и реализованном. Причем, чем больше базовых игровых фич вы откладываете на “потом”, с тем бОльшим количеством проблем столкнетесь в будущем, пытаясь впихивать новый функционал в уже устаканившуюся систему взаимодействия.

Понятно, что в реальности продумать все заранее невозможно, и вы постоянно будете сталкиваться с ситуацией, когда надо “добавить сюда еще вот это и вон то”. Это абсолютно нормально, будьте готовы к таким ситуациям: заранее закладывайте возможность добавления в экран новых элементов, обговаривайте этот вопрос с гейм-дизайнерами или проект-менеджерами (“как думаешь, что еще может добавиться на этот экран в ближайшей перспективе?”) Надо понимать, что у каждого экрана есть свой предел прочности, по достижении которого понимаешь, что проще все удалить и сделать по-другому, чем продолжать попытки впихнуть невпихуемое.

Это, кстати, классическая и неизбежная проблема проектов-долгожителей, особенно мобильных и браузерных. Чем дольше живет игра, чем шире и разнообразнее становится ее функционал, тем безобразнее, замусореннее выглядит ее интерфейс.

Шаг второй. Сборка прототипа, поиск стилистики.

Итак, у нас на руках есть дизайн-документ, общая, более-менее цельная заглушечная схема экранов и связей между ними. Теперь мы уже более-менее понимаем, какой объем работы по части интерфейса предстоит сделать, понимаем количество экранов и примерный набор элементов на каждом из них. Это прекрасный момент для того, чтобы начать собирать на коленке уродливый прототип интерфейса из квадратиков и кружочков. Да, вы никогда не покажете его своим друзьям и маме, но он ответит на множество вопросов, в том числе интерфейсных:

Параллельно со сборкой прототипа интерфейса (что обычно занимает время), имеет смысл начинать работы по поиску его стилистики и визуализации.

Почему не раньше, спросите вы? До схем и, возможно, даже до дизайн-документа? Можно и раньше. Но в таком случае вы рискуете столкнуться с (очень возможной) ситуацией, когда картинка, нарисованная по абстрактному ТЗ, совершенно не впишется в реальные требования конкретно вашего проекта, и придется искать стилистику с начала.

Перед началом отрисовки экранов исполнителю (художнику или дизайнеру — короче, тому кто будет отрисовывать) необходимо прежде всего максимально дотошно расспросить заказчика о том, каким он видит интерфейс проекта. На что тот будет похож? Какие игры (по мнению заказчика) близки к вашему проекту визуально и атмосферно? А какие игры нравятся самому заказчику, во что он играет, какие проекты уважает? Здорово, если у вас на руках уже будут какие-то атмосферные концепты, отражающие стилистику будущей игры, или фейк-скрины, но чаще всего подобная роскошь на этом этапе недоступна.

Вообще, общение с заказчиком — это очень важная часть работы, которая может сэкономить (или потерять, в случае пропуска) всем в производственной цепочке кучу времени. К сожалению, большинство дизайнеров сложно назвать эталоном по части общения с клиентом (я тут, кстати, не исключение). Именно поэтому так важно сделать над собой психологическое усилие, а также объяснить (как себе, так и заказчику) смысл и важность происходящего. Приемка интерфейсов, как и приемка арта — дело сугубо субъективное, от этого никуда не денешься, и крутится оно вокруг личности и системы ценностей заказчика. В процессе работы вы можете давать рекомендации или советы, высказывать мнения и приводить примеры, но последнее слово всегда остается за заказчиком или его представителем, и это логично. А заказчики бывают очень разные: кто-то хорошо представляет, чего хочет, кто-то — нет. Одни могут сформулировать запрос в виде картинок (что просто прекрасно), другие готовы описать на словах (что тоже неплохо), третьим не хватает насмотренности или опыта (а иногда и желания, т.к. они считают, что выполняют тем самым чужую работу) и им требуется помощь с формулировкой мыслей. Вообще, это тема для отдельной статьи. В рамках этого материала мы на этом задерживаться не будем.

Заметка на полях: требования и пожелания от заказчика лучше фиксировать в письменном виде — таким образом ему сложнее потом “передумать” или “забыть” сказанное. И никогда не соглашайтесь на “ой, не знаю, вы там давайте рисуйте что-нибудь, а там разберемся”. Это мартышкин труд, который никому не нужен, в том числе заказчику.

Результаты работы с интерфейсом на втором этапе:

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

Во-вторых, собран набор референсов для чистового визуала, которые нравятся и одобрены заказчиком. Каждый реф может зацепить заказчика чем-то конкретным (цветовой гаммой, решение главного меню, системой навигации) или просто общим впечатлением от картинки. Храните эти рефы как зеницу ока — они станут краеугольным камнем для следующего этапа.

Примеры реф-листов:

Заметка на полях: в первую очередь лучше набирать референсы из той же рыночной ниши, что и ваш проект. Дело в том, что если вы наберете отличные рефы из ААА игр для ПК, а сами занимаетесь разработкой мобильной игры, то согласовать-то их может быть будет и проще, а вот реализовать всю эту красоту в ограниченном мобильном формате будет практически невозможно. В результате на каком-то этапе вы столкнетесь с закономерным вопросом от заказчика: “Мы же подобрали такие крутые рефы, почему в результате получилось ВОТ ЭТО?”.

Еще одна заметка на полях: уделяйте на этом этапе побольше времени и сил изучению конкурентов. Смотрите скриншоты, читайте обзоры, проходите на ютубе, в конце концов. Чем больше будет ваша насмотренность, тем проще вам будет понять, что лучше работает (или не работает) в аналогичных проектах и тем легче аргументировать свое мнение. Не спешите изобретать велосипеды и не бойтесь простоты.

Шаг третий. Обкатка прототипа, отрисовка превью экранов.

Итак, у нас есть рабочий прототип, в котором реализован заглушечный интерфейс. Он, в целом, работает, выполняет свою функцию. А еще у нас есть визуальный ориентир для отрисовки экранов в виде набора референсов. Самое время их совместить: “одеть” несколько экранов в понравившуюся “шкурку”.

В процессе отбора рефов обычно становятся понятны основные направления для отрисовки первых экранов-превью: Скажем, если у вас sci-fi сеттинг, а в одобренных заказчиком рефах лежат Deus Ex и XCOM… ну, я бы сказал, что вам придется делать превью как минимум в двух вариациях:

А если в рефах лежат какие-то близкие по стилистике экраны (тот же XCOM и, скажем, Mass effect) а времени не очень много, то вполне можно обойтись и одним:

После того, как мы довели один экран-превью до состояния, которое нравится заказчику, имеет смысл отрисовать еще парочку в той же стилистике, выбирая их по принципу “максимально отличающихся”. К примеру, если первым был экран с небольшим количеством крупных элементов, то имеет смысл в дополнение к нему взять экран с большим количество маленьких элементов (например, инвентарь) и что-нибудь табличное (вроде таблицы рейтингов или статистики боя). Таким образом, вы уже на старте отработаете максимальное количество различных элементов и будете более-менее уверены в том, что выбранная “одежда” универсальна и будет достойно выглядеть на любом экране.

На этапе отрисовки превьюшек вполне можно пренебречь какими-то элементами или делать допущения в стиле “эту рамку потом придется подправить, иначе в движок ее не вставить” или «вот эти иконки надо будет подогнать под один размер». Здесь важно за минимальное количество времени получить максимально презентабельную, “продающую” картинку, которую уже не стыдно показывать инвесторам, использовать в презентациях и т.д.

Результат этого этапа: 3-4 отрисованных экрана “чистового” качества, одобренных заказчиком и обкатанная в прототипе схема интерфейса.

Шаг четвертый. Отрисовка экранов, составление UI kit’а, документация.

Это самый объемный этап работы с интерфейсом, занимающий примерно 70% всего рабочего времени. Причем для него у меня нет каких-то хитростей и лайф-хаков, только кропотливая работа и чугунный зад. Планомерно и постепенно, экран за экраном отрисовываются и внедряются в движок. Одновременно с этим обновляется их состав и функционал (потому что с момента рисовки схем обычно многое уже поменялось), а также составляется документация.

Пара слов о документации. Как показала практика, очень полезно описывать функционал экранов. Письменно. Для кого-то это прозвучит очевидным советом от кэпа, но вы удивитесь, как часто этот этап пропускают (особенно в небольших компаниях). Не в последнюю очередь это происходит потому что, во-первых, никто не любит бюрократии (у нас же тут геймдев и рок-н-ролл или что?), а во-вторых, потому что с документацией надо уметь работать. Это подразумевает как умение грамотно сформулировать описание со стороны ГД или UI/UX дизайнеров, так и умение и привычку использовать его при сборке экрана программистами. Ну и в-третьих, документацию ведь надо держать в свежем виде и регулярно обновлять. Это тоже требует времени, сил, желания и, главное, понимания, зачем оно всё нужно.

Без письменных описаний экранов вы рискуете столкнуться со всеми проблемами, связанными с человеческим фактором, забывчивостью и коммуникационными проблемами. Ваш UX-дизайнер внезапно увольняется и улетает на Бали. Программисты собирают экраны не так, как задумывалось, а так, как они считают правильным, апеллируя к тому, что “им про это не сказали”. Геймдизайнер или проект-менеджер забывает принятые решения, поскольку они не были зафиксированы, и всякий раз выдает новую версию.

Короче, приучайте себя к работе с документацией. Договоритесь внутри команды, как именно это делать: какая должна быть структура, какие инструменты использовать, на чем акцентировать внимание. А если вы уже вовсю пользуетесь документацией на проекте и сейчас только понимающе усмехаетесь, покручивая ус — берите печеньку, вы клёвые.

Дальше немного про GUI pack (или, как его еще называют, UI kit или design case). После отрисовки нескольких базовых экранов обычно становится понятен основной набор элементов, из которых будет состоять ваш интерфейс, а также правила их компановки. При дальнейшей работе с экранами будет примерно на 60-80% состоять из реюза уже готовых элементов по уже готовым правилам. Имеет смысл вынести этот “конструктор” с элементами и описаниями в отдельный, эталонный файл. Выглядит он примерно вот так:

Автор изображения — Johnny Waterman

С готовым UI KIT’ом все в команде (особенно это актуально для верстальщиков и программистов) будут знать, где содержатся самые последние, эталонные версии всех интерфейсных элементов. В то же время, в макетах конкретных экранов дизайнерам можно будет не держать десятки дублирующих слоев вроде всех состояний кнопок и переключателей.

Шаг пятый. Внедрение в игровой движок, контроль качества.

Этот этап выделен условно, т.к. сборка интерфейсов в движке обычно идет параллельно их разработке. Взяли экран со схемы, отрисовали, нарезали, отдали программистам, взялись за следующий. При этом вы “ведете” экран, находящийся в производстве, до победного конца. Только когда он собран в версии для целевых устройств (кстати, вы же не забыли про планшеты?), выглядит и работает на них так, как планировалось изначально, вы можете облегченно выдохнуть и мысленно поставить галочку в графе “сделано”. До следующей итерации.

Помните, что результат работы UX/UI специалистов — не статичная фотошопная картинка и не абстрактная схема, а красивый и, главное, функциональный интерфейс, с которым будет работать пользователь. То, насколько хорош финальный продукт, показывает, настолько хороши конкретно вы как специалист. Поэтому будьте строги и внимательны ко всем звеньям в производственной цепи, и в первую очередь к себе. Не закрывайте глаза на всякую лажу под предлогом того, что это “не моя ответственность”.

Шаг шестой. Полировка и добавление анимаций.

Это бонусный этап. Будем откровенны: при приближении даты релиза (обычно уже несколько раз перенесенной) у всех в команде начинают пылать различные части тела. Времени на полировку (а особенно полировку интерфейса, которому исторически отводят второстепенное значение) никогда не хватает. Поэтому важно изначально задумываться о том, что и когда вы будете доделывать, а также об интерфейсных анимациях. Есть возможность — добавляйте их сразу, еще при первой сборке экрана. Нет такой возможности — выделите на это отдельное, конкретное время в планах разработки. Жестко стойте на своем и не соглашайтесь отодвигать доделки и анимации на неопределенное “потом”, регулярно напоминайте про них.

Хороший игровой интерфейс “живет” и динамично реагирует на действия игроков. Интерфейсная анимация — как щепотка специй, способная преобразить вкус и ощущения от всего “блюда”. Она делает интерфейс более плавным, связанным, последовательным. Она сглаживает резкие переходы, привлекает внимание к нужным местам, развлекает — короче, улучшает игровой опыт пользователей в целом. При этом, как и в кулинарии, важно не переборщить и не поддаться искушению заанимировать всё подряд. Знайте меру.

Шаг седьмой. Аналитика интерфейсов.

Еще один условно-бонусный этап. В идеальном мире разработчики проверяют основные гипотезы (в т.ч. интерфейсные), привлекая для тестов реальных пользователей из своей ЦА, и принимают решения, исходя из полученных данных. При правильном подходе такой метод позволяет (в теории) отразить более-менее объективное положение дел и дать ответ на вопрос, что в интерфейсе действительно работает, а что нет.

В реальности такое встречается редко: не все могут позволить себе дорогостоящие плей-тесты, мало кто умеет с ними работать и понимает, зачем они нужны. Даже после софт-ланча часто анализируются только базовые показатели вроде DAU, WAU ROI и т.п., не касающиеся напрямую интерфейсов. Т.е. то, что какая-то кнопка никуда не ведет, на этапе софт-ланча заметят, а вот то, что игроки не догадываются вызвать всплывающую по тапу подсказку, уже нет.

В своей практике я, к своему сожалению и стыду, до сих пор еще не сталкивался с полноценным UX-тестированием и последующей аналитикой результатов. Основным методом принятия решений всегда была т.н. “экспертная” оценка. Это когда решения по теме принимает одно лицо (или небольшая группа лиц) которое, как считается, обладает необходимым опытом и компетенцией. Понятно, что это не самый точный и, мягко говоря, довольно субъективный метод.

Однако тот факт, что я лично не сталкивался в с UX-тестированием в геймдеве, не означает, что его не существует в природе. Насколько мне известно, отдельные игровые компании имеют возможность и желание проводить полноценные плей-тесты и активно ими пользуются. Мне очень интересно было бы узнать об их методиках и результатах, а также о том, как они к этому пришли к организации подобных мероприятий. Если вам есть что сказать на эту тему — пожалуйста, свяжитесь со мной или расскажите об этом опыте в комментариях или собственном материале.

На этом, пожалуй, всё. Несмотря на то, что многие вещи я обрисовал очень коротко или пропустил вовсе, статья вышла объемнее, чем рассчитывалась изначально. Спасибо, что были стойкими и дочитали ее до конца! Надеюсь, что вы нашли для себя что-то полезное и интересное. Будет вдвойне приятно, если что-то из прочитанного показалось вам достаточно интересным для того, чтобы опробовать это на практике.

Буду благодарен за любые комментарии, вопросы и замечания по сути, а также просто интересные истории из жизни, связанные с игровыми интерфейсами. Не стесняйтесь писать на почту.

Всем удачи!

Разница между веб-разработчиком и разработчиком пользовательского интерфейса

Содержимое

1. Кто является веб-разработчиком
2. Навыки, необходимые веб-разработчику
3. Личные навыки, необходимые веб-разработчику
4. Кто является разработчиком пользовательского интерфейса
5. Навыки, необходимые разработчику пользовательского интерфейса
6 Личные навыки, необходимые разработчику пользовательского интерфейса
7. Чем отличается веб-разработчик от разработчика пользовательского интерфейса
8.Вывод

Разработка работает в известном пространстве и пытается созреть, исправить или развить какую-то интересную или несуществующую работу.

Веб-разработчик

Веб-разработчика можно определить как специалиста, обладающего предметными знаниями в области Интернета, веб-архитектуры и технологий. Они занимаются созданием веб-сайта / приложения от базового HTML до базы данных.

Таким образом, веб-разработчик несет ответственность за создание веб-сайта с нуля и за то, чтобы конечный пользователь не испытывал затруднений при навигации по веб-сайту или приложению.Более того, веб-сайт или приложение не должны быть слишком простыми или слишком сложными для опытных пользователей и новичков. Это поможет сократить количество случаев, когда посетитель покидает сайт, не переходя по другим веб-страницам.

В веб-разработке три части:

Клиентские сценарии: — Это код, который выполняется в веб-браузерах и определяет, что пользователи / клиенты увидят сразу после перехода на веб-страницу или приложение.
Сценарии на стороне сервера: — Это код, который выполняется на веб-сервере и управляет внутренними механизмами.
Технология баз данных: — Это то, что веб-сайт и приложение используют для обеспечения его эффективной и бесперебойной работы.

В связи с этим существует три типа веб-разработчиков; Front-end разработчик, back-end разработчик и full-stack разработчик. Интерфейсный разработчик в основном занимается общим видом веб-сайта или приложения, а внутренний разработчик занимается фоном и следит за тем, чтобы все функции работали. Для разработчиков полного стека они обладают знаниями в области интерфейсной и внутренней разработки.

Обычно веб-разработчики имеют дело с тем, как веб-сайт работает, начиная с его внешнего вида, функций и взаимодействия.

Навыки, необходимые веб-разработчику

Чтобы быть веб-разработчиком, вам необходимо хорошо разбираться в HTML, CSS, JavaScript, jQuery и технологиях на стороне клиента. В основном это относится к интерфейсным разработчикам.

• Веб-разработчик также должен быть экспертом в языках программирования. К ним относятся PHP, Ruby, ASP, Java, C, C ++, Python, Bash и многие другие.
• Веб-разработчик также должен быть экспертом в создании и обслуживании баз данных. К ним относятся MySQL.
• Знают, как создавать и поддерживать веб-сайты и приложения.
• Им также необходимо знать, как покупать домен и веб-хостинг.
• Им обычно необходимо знать, как создать макет веб-сайта, его функционирование и возможности взаимодействия.
• Они также проверяют совместимость сайта со всеми веб-браузерами и проводят тестирование и обновление по мере необходимости.
• Как веб-разработчик, вам также необходимо знать, как настраивать и использовать системы управления контентом (CMS).К ним относятся WordPress, Joomla и Drupal.
• Разработчику также важно знать, как создавать интернет-магазины с использованием платформ электронной коммерции.

Личные навыки, необходимые веб-разработчику

Помимо профессиональных навыков, веб-разработчик также должен уметь взаимодействовать с людьми. К ним относятся клиенты, члены команды, веб-дизайнеры, разработчики пользовательского интерфейса, разработчики UX, разработчики программного обеспечения и многие другие.

Как веб-разработчик, также важно хорошо распоряжаться своим временем; это сделано для того, чтобы вы смогли сократить сроки выполнения работ.

Веб-разработчик также должен быть хорошим коммуникатором. Поскольку они работают в группах, а не в одиночку, им необходимо иметь возможность работать в группах, а не над индивидуальными проектами.

Еще надо быть менеджером проекта; потому что разработка часто рассматривается как проект. Хорошие управленческие навыки также необходимы для эффективного общения и завершения работы.

Разработчик пользовательского интерфейса

Пользовательский интерфейс — это термин, определяющий все, с чем пользователь может взаимодействовать при использовании такого устройства, как ноутбук.Сюда входят экран, клавиатура, мышь и внешний вид приложения, веб-сайта и графики. Основная цель дизайна пользовательского интерфейса — сделать взаимодействие пользователя максимально простым.

Разработчик пользовательского интерфейса обычно использует HTML, CSS, jQuery, клиентские технологии и JavaScript. Однако, в отличие от фронтального разработчика, который делает упор на всех из них, разработчик пользовательского интерфейса, как правило, уделяет больше внимания HTML и CSS. Таким образом, разработчик пользовательского интерфейса стремится сосредоточиться на аспекте дизайна и взаимодействии веб-сайта / приложения.

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

Как правило, это просто человек, обладающий определенными навыками, связанными с внешним видом, ощущениями и взаимодействием с веб-сайтом или приложением.

Уникальный аспект разработчиков пользовательского интерфейса

Они сосредоточены на том, как отображаются функции и как пользователи будут взаимодействовать с конкретным интерфейсом.Эти разработчики склонны сочетать в своей работе как дизайнерские, так и технические навыки. Таким образом, они делают приложение или веб-сайт красивым и в то же время функционируют должным образом.

Они легко создают визуальный дизайн, как графические дизайнеры, и превращают его в HTML-код, чтобы обеспечить совместимость с браузером. Они часто опасаются совместимости браузеров, чтобы гарантировать, что интерактивность веб-страницы не будет нарушена.

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

Удивительно, но если они получают уже написанный код, они делают его лучше и функциональнее, чем был.

Навыки, необходимые для разработчика пользовательского интерфейса

• Разработчик пользовательского интерфейса должен знать графику и графические программы.
• Они также должны хорошо владеть языками программирования и кодированием.
• Будучи разработчиком, вы должны обладать хорошими техническими навыками.
• Разработчик пользовательского интерфейса также должен обладать достаточными знаниями в области дизайна и создания великолепного внешнего вида.
• Также важно знать HTML, CSS, JavaScript и клиентские технологии.
• Знание браузеров и их совместимости.
• Разработчику пользовательского интерфейса также необходимо разработать архитектуру для каждого компонента, который предоставляет элементы для всего приложения.
• Поскольку они работают в тесном сотрудничестве с другими разработчиками, им необходимо знать, как создать удобство для пользователей.

Личные навыки, необходимые разработчику пользовательского интерфейса

Разработчик пользовательского интерфейса должен быть хорошим командным игроком, потому что он работает не в одиночку, а с другими.Более того, важно быть хорошим координатором для эффективной работы с командой разработчиков и продукта.

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

Также важно хорошо разбираться в сроках и быть отличным менеджером проекта, чтобы все работало хорошо.

Уметь работать в соответствии с рекомендациями разработчиков систем, чтобы разработать потрясающую гибкую архитектуру пользовательского интерфейса.

Разработчикам пользовательского интерфейса важно быть в курсе последних технологий, стандартов и тенденций.

Что отличает веб-разработчика от разработчика пользовательского интерфейса?

Навыки
Во-первых, навыки, необходимые разработчику пользовательского интерфейса, отличаются от навыков, которые необходимы веб-разработчику. Веб-разработка, как правило, сложнее, чем проектирование и разработка пользовательского интерфейса. Тем не менее, технические навыки важны для обеих профессий, но разница — это их уровень.

Operation
И пользовательский интерфейс, и веб-разработчик работают с другими профессионалами, чтобы обеспечить работу веб-сайта или приложения в короткие сроки. Однако веб-разработчик полного стека может легко работать со своим без какой-либо помощи. Разработчик пользовательского интерфейса обязан работать с другими, чтобы гарантировать, что создание выполнено на 100%.

Exposure
Веб-разработчики обычно более открыты, чем разработчики пользовательского интерфейса. Это связано с тем, что последние ограничены некоторыми ресурсами, в то время как веб-разработчик может легко получить доступ к любому ресурсу.

Опыт
В некоторой степени разработчиков пользовательского интерфейса называют разработчиками интерфейса. Веб-разработчик с полным стеком, как правило, обладает навыками фронтенд-разработчика и многим другим и считается более продвинутым, чем эксперты по пользовательскому интерфейсу. Веб-разработчик может работать без разработчика пользовательского интерфейса, в отличие от разработчика пользовательского интерфейса, который не может работать в одиночку.

Заключение: —
Подводя итог, важны как разработчики пользовательского интерфейса, так и веб-разработчики. Они работают по-разному, но работают для достижения одного и того же результата и предлагают решение технологических проблем.Насколько продвинутый человек; делает профессиональную разницу между ними.

В следующий раз, когда вы увидите работающее приложение или веб-сайт, знайте, что оно было создано командой разработчиков. Если вы хотите окунуться в мир Интернета, будьте уверены, что для этого потребуется много усилий.

.

Как стать разработчиком интерфейсов

Разработчики программного обеспечения обычно имеют степень бакалавра компьютерных наук и сильные навыки программирования.

Образование

Разработчики программного обеспечения обычно имеют степень бакалавра, как правило, в области компьютерных наук, разработки программного обеспечения или в смежных областях. Также приемлемо диплом по математике. Программы получения степени по информатике являются наиболее распространенными, поскольку они, как правило, охватывают широкий круг тем.Студенты должны сосредоточиться на занятиях, связанных с созданием программного обеспечения, чтобы лучше подготовиться к работе по специальности. Для некоторых должностей работодатели могут предпочесть степень магистра.

Хотя написание кода не является их первоочередной задачей, разработчики должны иметь большой опыт в компьютерном программировании. Обычно они получают этот опыт в школе. На протяжении всей своей карьеры разработчики должны быть в курсе новых инструментов и компьютерных языков.

Разработчикам программного обеспечения также необходимы навыки, связанные с отраслью, в которой они работают.Например, разработчики, работающие в банке, должны знать финансы, чтобы понимать потребности банка в вычислительной технике.

Другой опыт

Многие студенты получают опыт разработки программного обеспечения, проходя стажировку в компании-разработчике программного обеспечения во время учебы в колледже.

Некоторые разработчики программного обеспечения сначала работают программистами, а затем по мере накопления опыта на них возлагается больше ответственности. В конце концов они становятся разработчиками.

Продвижение

Разработчики программного обеспечения могут стать менеджерами проектов в области информационных технологий (ИТ), также называемыми менеджерами компьютеров и информационных систем, — должность, на которой они контролируют процесс разработки программного обеспечения.

Важные качества

Аналитические навыки. Разработчики должны анализировать потребности пользователей, а затем разрабатывать программное обеспечение для удовлетворения этих потребностей.

Коммуникативные навыки .Разработчики должны уметь давать четкие инструкции другим, работающим над проектом. Они также должны объяснить своим клиентам, как работает программное обеспечение, и ответить на любые возникающие вопросы.

Компьютерные навыки. Разработчики должны понимать возможности компьютера и языки программирования, чтобы создавать эффективное программное обеспечение.

Творчество. Разработчики — творческие умы, стоящие за новым компьютерным программным обеспечением.

Детально. Разработчики часто работают над многими частями приложения или системы одновременно, поэтому они должны уметь концентрироваться и обращать внимание на детали.

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

Навыки решения проблем. Поскольку разработчики отвечают за программное обеспечение от начала до конца, они должны уметь решать проблемы, возникающие в процессе проектирования.

.

кнопок — вход через Apple — рекомендации по человеческому интерфейсу

Кнопки

Apple предоставляет несколько кнопок «Войти с помощью Apple», которые можно использовать, чтобы позволить людям создать учетную запись и выполнить вход. При необходимости вы можете создать настраиваемую кнопку, предлагающую «Войти с помощью Apple»; инструкции см. в разделе «Создание пользовательского входа с помощью кнопки Apple».

Заметно отобразить кнопку «Войти с помощью Apple». Сделайте кнопку «Войти с помощью Apple» размером не меньше, чем другие кнопки входа, и не заставляйте людей прокручивать страницу, чтобы увидеть кнопку.

Использование системных кнопок

При использовании предоставленных системой API-интерфейсов для создания кнопки «Войти с помощью Apple» вы получаете следующие преимущества.

• Кнопка, на которой гарантированно используются одобренные Apple заголовок, шрифт, цвет и стиль
• Гарантия того, что содержимое кнопки сохраняет идеальные пропорции при изменении ее стиля
• Автоматический перевод названия кнопки на язык, указанный устройством
• Поддержка настройки радиуса угла кнопки в соответствии со стилем вашего пользовательского интерфейса (iOS, macOS и Интернет)
• Предоставляемая системой альтернативная текстовая метка, позволяющая VoiceOver описывать кнопку

Инструкции для разработчиков см. В разделах ASAuthorizationAppleIDButton (iOS, macOS и tvOS), WKInterfaceAuthorizationAppleIDButton (watchOS) и Displaying and Configuring Sign in with Apple Buttons (web).Вы также можете посетить Вход с помощью кнопки Apple, чтобы просмотреть и настроить предварительный просмотр веб-кнопок и получить код в реальном времени.

В системе предусмотрено несколько вариантов названия кнопки. В зависимости от платформы, на которой работает ваш контент, выберите вариант, соответствующий терминологии вашего входа в систему, и используйте его последовательно во всех интерфейсах.

Следующие названия кнопок доступны для iOS, macOS, tvOS и в Интернете:

Для watchOS система предоставляет один заголовок:  Войти.

В зависимости от платформы в системе предусмотрено до трех вариантов внешнего вида кнопки «Войти через Apple»: белый, белый с контуром и черный. Выберите внешний вид, который лучше всего сочетается с фоном, на котором отображается кнопка.

Белый

Белый стиль доступен на всех платформах и в Интернете. Используйте этот стиль на темном или цветном фоне, обеспечивающем достаточный контраст.

Белый с контуром

Стиль с белой рамкой доступен в iOS, macOS и в Интернете.Используйте этот стиль для белого или светлого фона, который не обеспечивает достаточного контраста с заливкой белой кнопки. Избегайте использования этого стиля на темном или насыщенном фоне, потому что черный контур может добавить визуального беспорядка; вместо этого используйте белый стиль, чтобы контрастировать с темным фоном.

Черный

Черный стиль доступен на всех платформах и в Интернете. Используйте этот стиль на белом или светлом фоне, обеспечивающем достаточный контраст; не используйте его на черном или темном фоне.

В отличие от черной кнопки «Войти с помощью Apple» для других платформ, кнопка watchOS использует не полностью черный цвет заливки. Чтобы контрастировать с чисто черным фоном Apple Watch, кнопка watchOS имеет темно-серый вид, определенный системой.

Размер кнопки и угловой радиус

Отрегулируйте радиус угла в соответствии с внешним видом других кнопок в вашем приложении. По умолчанию кнопка «Войти через Apple» имеет закругленные углы. В iOS, macOS и в Интернете вы можете изменить радиус угла, чтобы создать кнопку с квадратными углами или кнопку в форме таблетки.Рекомендации для разработчиков см. В разделах cornerRadius (iOS и macOS) и Отображение и настройка входа с помощью кнопок Apple (Интернет).

Минимальный радиус закругления

Радиус закругления по умолчанию

Максимальный радиус закругления

Поддерживайте минимальный размер кнопки и поля вокруг кнопки в iOS, macOS и в Интернете. Помните, что заголовок кнопки может различаться по длине в зависимости от региона. Используйте следующие значения в качестве руководства.

Создание пользовательского входа с помощью кнопки Apple

Если ваш макет требует этого, вы можете создать пользовательскую кнопку «Войти с помощью Apple» для iOS, macOS или в Интернете. Например, если вы поддерживаете несколько методов входа, вам может потребоваться отобразить кнопки входа, которые используют логотипы с выравниванием по левому краю или отображают только логотип.

Apple Design Resources предоставляет загружаемые изображения логотипа Apple, которые можно использовать для создания настраиваемого выравнивания по левому краю или только логотипа. Вход с помощью кнопок Apple. Файлы логотипов доступны в форматах PNG, SVG и PDF, а изображения для обоих типов кнопок имеют два вида. Вот примеры черно-белых графических файлов с логотипом, каждый с добавленным фоном для наглядности.

Все загружаемые файлы логотипов включают отступ, позволяющий легко разместить логотип на кнопке:

• Файлы логотипов с выравниванием по левому краю включают вертикальные отступы, обеспечивающие правильную пропорцию логотипа относительно кнопки, и горизонтальные отступы, обеспечивающие минимальное поле между логотипом и левым краем кнопки и заголовком.

Файлы логотипов

• , содержащие только логотипы, включают горизонтальные и вертикальные отступы, которые обеспечивают правильную пропорцию логотипа относительно кнопки.

Используйте только логотипы, загруженные с Apple Design Resources. Следуйте этим инструкциям, чтобы создать и разместить загружаемые файлы логотипов:

• Используйте файл логотипа, чтобы разместить логотип Apple на кнопке; никогда не используйте логотип Apple в качестве кнопки.
• Совместите высоту файла логотипа с высотой кнопки.
• Не обрезать файл логотипа.
• Не добавлять вертикальные отступы.
• Не используйте собственный цвет в файле логотипа.

Кнопки с логотипом выровнены по левому краю

Выберите формат файла логотипа в зависимости от высоты вашей кнопки. Поскольку SVG и PDF являются векторными форматами, вы можете использовать эти файлы в кнопках любой высоты. Используйте файлы PNG только в кнопках высотой 44 пункта, что является высотой кнопки по умолчанию (и рекомендуется) в iOS. Кроме того, выровненные по левому краю логотипы доступны в малых, средних и больших размерах, поэтому вы можете сопоставить размеры логотипов на всех отображаемых вами кнопках регистрации.

Используйте системный шрифт для названия, то есть «Войти в Apple», «Зарегистрируйтесь в Apple» или «Продолжить в Apple». Чтобы выглядеть правильно, заголовок и высота вашей настраиваемой кнопки должны иметь те же пропорции, что и система. В частности, размер шрифта заголовка должен составлять 43% от высоты кнопки — другими словами, высота кнопки должна составлять 233% от размера шрифта заголовка с округлением до ближайшего целого числа. Вот два примера, иллюстрирующие эти пропорции.

Сохранить стиль заглавной буквы в заголовке. Во всех вариантах названия кнопки первое слово пишется с заглавной буквы, то есть Подпись или Продолжить — и Apple ; все остальные буквы строчные. Не изменяйте этот стиль, например, переводя каждую букву в заголовок с заглавной буквы.

Сохраняйте выравнивание заголовка и логотипа по вертикали внутри кнопки. Для этого выровняйте заголовок по вертикали по центру кнопки, затем добавьте изображение логотипа, убедившись, что его высота соответствует высоте кнопки.Поскольку изображение логотипа включает верхнее и нижнее отступы, вертикальное выравнивание заголовка в кнопке гарантирует, что заголовок, логотип и кнопка останутся правильно выровненными.

При необходимости вставьте логотип. Если вам нужно выровнять логотип Apple по горизонтали с другими логотипами аутентификации, вы можете вставить левую часть логотипа.

Сохраняйте минимальное расстояние между заголовком и правым краем кнопки. Поле должно составлять не менее 8% ширины кнопки.

Сохраняйте минимальный размер кнопки и поля вокруг кнопки. Помните, что заголовок кнопки может различаться по длине в зависимости от региона. Используйте следующие значения в качестве руководства.

Кнопки только для логотипа

Выберите формат файла логотипа в зависимости от размера вашей кнопки. Как и изображения для кнопок с логотипом, выровненных по левому краю, загружаемые изображения для кнопок с логотипом доступны в форматах SVG, PDF и PNG. Используйте векторные форматы SVG и PDF для кнопок любого размера; используйте формат PNG только в кнопках размером 44pt × 44pt.

Не добавляйте горизонтальные отступы к изображению только с логотипом. Кнопка «Войти с помощью Apple» только с логотипом всегда имеет соотношение сторон 1: 1, а изображение уже включает правильные отступы со всех сторон.

Используйте маску, чтобы изменить квадратную форму по умолчанию для изображения только логотипа. Например, вы можете использовать круглую или закругленную прямоугольную форму для представления всех кнопок входа только с логотипом. Никогда не обрезайте предоставленные Apple иллюстрации, чтобы уменьшить их встроенные отступы, и не используйте логотип отдельно, а также избегайте добавления дополнительных отступов.

Маска прямоугольника со скругленными углами

Без маски

Круглая маска

Сохраняйте минимальное поле вокруг кнопки. Поле должно составлять не менее 1/10 высоты пуговицы.

.

Обзор пользовательского интерфейса

Переключить навигацию

• Инструменты разработки
  • Какие инструменты мне нужны?
  • Программные средства
    • Начни здесь
    • MPLAB® X IDE
      • Начни здесь
      • Установка
      • Введение в среду разработки MPLAB X
      • Переход на MPLAB X IDE
        • Переход с MPLAB IDE v8
        • Переход с Atmel Studio
      • Конфигурация
      • Плагины
      • Пользовательский интерфейс
      • Проектов
      • файлов
      • Редактор
        • Редактор
        • Интерфейс и ярлыки
        • Основные задачи
        • Внешний вид
        • Динамическая обратная связь
        • Навигация
        • Поиск, замена и рефакторинг
        • Инструменты повышения производительности
          • Инструменты повышения производительности
          • Автоматическое форматирование кода
          • Список задач
          • Сравнение файлов (разница)
          • Создать документацию
      • Управление окнами
      • Сочетания клавиш
      • Отладка
      • Контроль версий
      • Автоматизация
        • Язык управления стимулами (SCL)
        • Отладчик командной строки (MDB)
        • Создание сценариев IDE с помощью Groovy
      • Поиск и устранение неисправностей
      • Работа вне MPLAB X IDE
      • Прочие ресурсы
    • MPLAB Xpress
    • MPLAB IPE
    • Программирование на C
    • Компиляторы MPLAB® XC
      • Начни здесь
      • Компилятор MPLAB® XC8
      • Компилятор MPLAB XC16
      • Компилятор MPLAB XC32
      • Компилятор MPLAB XC32 ++

      Охват кода

      • MPLAB
    • Компилятор IAR C / C ++
    • Конфигуратор кода MPLAB (MCC)
    • Гармония MPLAB v2
    • Гармония MPLAB v3
    • среда разработки Atmel® Studio
    • Atmel СТАРТ (ASF4)
    • Advanced Software Framework v3 (ASF3)
      • Начни здесь
      • ASF3 Учебники
        • ASF Audio Sine Tone Учебное пособие
        • Интерфейс ЖК-дисплея с SAM L22 MCU Учебное пособие
    • Блоки устройств MPLAB® для Simulink®
    • Утилиты

    Инструменты проектирования

    • FPGA
    • Аналоговый симулятор MPLAB® Mindi ™
  • Аппаратные средства
    • Начни здесь
    • Сравнение аппаратных средств
    • Средства отладки и память устройства
    • Исполнительный отладчик
    • Демо-платы и стартовые наборы
    • Внутрисхемный эмулятор MPLAB® REAL ICE ™
    • Эмулятор SAM-ICE JTAG

    Внутрисхемный эмулятор

    • Atmel® ICE
    • Power Debugger
    • Внутрисхемный отладчик MPLAB® ICD 3
    • Внутрисхемный отладчик MPLAB® ICD 4

    Внутрисхемный отладчик

    • PICkit ™ 3
    • Внутрисхемный отладчик MPLAB® PICkit ™ 4
    • MPLAB® Snap
    • MPLAB PM3 Универсальный программатор устройств
    • Принадлежности
      • Заголовки эмуляции и пакеты расширения эмуляции
      • Пакеты расширения процессора и отладочные заголовки
        • Начни здесь

        Обзор

        • PEP и отладочных заголовков
        • Требуемый список заголовков отладки
          • Таблица обязательных отладочных заголовков
          • AC162050, AC162058
          • AC162052, AC162055, AC162056, AC162057
          • AC162053, AC162054
          • AC162059, AC162070, AC162096
          • AC162060
          • AC162061
          • AC162066
          • AC162083
          • AC244023, AC244024
          • AC244028
          • AC244045
          • AC244051, AC244052, AC244061
          • AC244062
        • Необязательный список заголовков отладки
          • Список необязательных отладочных заголовков — устройства PIC12 / 16
          • Дополнительный список заголовков отладки — устройства PIC18
          • Дополнительный список заголовков отладки — Устройства PIC24
        • Целевые следы заголовка отладки
        • Отладочные подключения заголовков
    • SEGGER J-Link

    Решения для сетевых инструментов

    • K2L
    • Рекомендации по проектированию средств разработки
    • Ограничения отладки — микроконтроллеры PIC
    • Инженерно-технические примечания (ETN) [[li]] Встраиваемые платформы chipKIT ™

• Проектов
  • Начни здесь
  • Преобразование мощности
    • AN2039 Четырехканальный секвенсор питания PIC16F1XXX
  • 8-битные микроконтроллеры PIC®
  • 8-битные микроконтроллеры AVR®
  • 16-битные микроконтроллеры PIC®
  • 32-битные микроконтроллеры SAM
  • 32-разрядные микропроцессоры SAM
    • Разработка приложений SAM MPU с MPLAB X IDE

    Примеры пакетов программного обеспечения

    • SAM MPU
  • Запланировано дополнительное содержание…

• Продукты
  • 8-битные микроконтроллеры PIC
  • 8-битные микроконтроллеры AVR

.