Всем привет!

В этом году Уральский федеральный университет в 16-й раз проведет Вузовско-академическую олимпиаду по информатике, вошедшую в 2020/21 учебном году в перечень РСОШ с III уровнем. Приглашаем школьников всех возрастов принять в ней участие!

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

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

Подайте заявку на участие!

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

Коротко о проекте

Разработка игры — большой кросс-дисциплинарный проект, который тесно связан с тремя курсами учебной программы: основами программирования, основами дизайна и основами проектной деятельности.

Почему такое задание?

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

А почему именно игра? Многих программистов в IT привело именно желание делать игры. Это интересная и творческая работа, в которой есть место для самовыражения, но при этом довольно сложная со множеством нюансов. К тому же игра — это наглядный и понятный результат усилий, который можно показать друзьям и родственникам.

Требования к проекту

Мы специально не стали заставлять ребят собирать требования заказчика. Этим они будут заниматься в других курсах дальше. Тут мы хотели дать свободу выбора, чтобы они сами решали, какую игру хотят делать. Хочешь сделать платформер? Вперед! Шутер? Тоже круто!

Однако мы установили несколько технических требований. Так, в каждой игре должно быть:

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

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

В курсе основ программирования (ОП) ребята освоили C#, поэтому и игру они пишут на этом языке. Также перед началом проекта мы показали студентам видеолекции о создании приложений с интерфейсом на WinForms и даже дали пару примеров готовых простых игр на этой технологии. Однако использовать именно WinForms было не обязательно. Несколько команд использовали игровой движок Unity, который в целом облегчает труд разработчика и берет большую часть работы на себя. На WinForms кода приходилось писать больше, однако на курсе мы не учили студентов работать с движками, поэтому с Unity им приходилось разбираться полностью самостоятельно. Каждый выбирал сам чего он хотел — разбираться в движках или писать больше кода самостоятельно.

Командная работа

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

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

Наставники

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

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

Сколько длится проект

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

О набивании шишек

Слушать о трудностях в разработке — одно. Совсем другое — столкнуться с ними на практике и учиться решать проблемы самостоятельно.

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

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

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

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

Защита

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

Предзащита

Для предзащиты каждая команда готовит видео, в котором кратко рассказывает, о чем игра, а также показывает геймплей и основные фишки.

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

После показа преподаватели выставляют оценки. На итоговый балл влияют четыре показателя:

• Геймплей. Преподаватели смотрят, насколько интересно играть, обращают внимание на сложность и оригинальность игровых механик.
• Удобство и понятность. Игра не должна ставить игрока в тупик, он должен понимать, что нужно делать и как управлять своим героем.
• Содержание. Тут изучают проработку сюжета и персонажей, а также атмосферу и оригинальность мира игры в целом.
• Оформление. Какие графику, визуальный стиль и звуковое сопровождение используют студенты? Некоторые рисовали графику и записывали звуки сами, а кто-то подбирал ассеты в открытых источниках. На оценку влияло только то, насколько гармонично сочетаются все элементы.

Чтобы пройти в финал, в игре должны сойтись все четыре показателя. Так, у нас были игры с крутой технической начинкой, но плохой играбельностью. Они получили хорошую оценку, но в следующий этап не попали. В итоге в финале встретились 11 команд. Мы планировали, что их будет 8, но игры были слишком хороши.

Финал

В финале 11 лучших игр оценивали уже не преподаватели, а настоящие эксперты эксперты игровой индустрии. В этом году в состав жюри вошли геймдизайнер Targem Games Ежи Красовский, организатор Ural Game Jam Глеб Багняк, старший аналитик Targem Games Игорь Кушнарев, а также известный независимый разработчик игр в России Денис Галанин.

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

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

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

Хотите увидеть обсуждение игр, которые заняли первые три места, а также самую красочную игру? Посмотрите 4 ролика:

1 место. Game #001

2 место. Хэш кот

3 место. Glasses Armies

)

“Зрительские симпатии”: Baldwin’s adventure

А еще в эти игры можно поиграть. Скачать понравившуюся игру можно тут:

• 1 место. Game #001
• 2 место. Хэш кот
• 3 место. Glasses Armies
• “Зрительские симпатии”: Baldwin’s adventure

FAQ

Я подумал, какие вопросы могут возникнуть у читателя, и постарался сразу ответить на них. Если хотите узнать что-то еще, пишите свой вопрос в комментариях.

Не простое ли задание для первого курса?

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

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

Можно вписаться в сильную команду, сложить ножки и ничего не делать?

Самостоятельная работа не означает, что преподаватели совсем не следят за студентами. Если один из членов команды пропадет или перестанет работать, преподаватели помогают команду реорганизовать.

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

Что думают о проекте студенты, преподаватели и эксперты

Виктория Браун, команда «Хэшкот»:

«Обычно нам давали небольшие практики с четкими требованиями. Преподаватели следили за всем, оставляли комментарии. А тут дали свободу — разрешили придумать все, что захочется, а потом сделать то, что напридумывали. Да, что-то не получается, постоянно не хватает времени… Но когда ты наблюдаешь за тем, как преподаватель играет в твою игру и хвалит ее — это самое крутое чувство.

Когда мы взялись за игру, ни у меня, ни у девочек из команды опыта с Unity не было. Ориентировались в основном на интернет: изучали статьи, форумы, видео на ютубе, документацию самого движка Unity. Ну и подключали свой игровой опыт. Плюс в процессе разработки преподаватель и одногруппники давали обратную связь, что убрать, что добавить, что поменять».

Степан Юрченко, команда «Tower of Durlag»:

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

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

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

Александр Панкратов, преподаватель курса «Основы программирования»:

«Такой проект в завершении первого года обучения мотивирует ребят использовать знания, которые они получили на первом году учебы. Эти знания — не мертвые, они нужны уже здесь и сейчас. Да и какой программист откажется написать игру?».

Ежи Красовский, геймдизайнер Targem Games

«Алекс Хирш, автор сериала “Gravity Falls” как-то взял интервью у Джастина Ройланда, автора Рик и Морти.

В нем они говорят важные слова о том, как перестать бояться и начать делать клевые штуки. Если коротко передать суть:

• Ставьте прикольные достижимые цели каждый месяц;
• Не бойтесь сделать плохо. Делайте много маленьких проектов — от комикса до маленькой игры, так вы увидите, как прогрессируете — даже если все еще будете недовольны результатом.
• У вас должны быть зрители — они помогут оценить себя со стороны.

Этот проект идеален, чтобы начать делать клевые штуки. Создание игры — многоплановая задача: код, арт, UX, звук. Студенты узнают в процессе кучу нового. У них может получится “в дизайн”, а может получится настоящий продукт, приносящий удовольствие людям.

В итоге получившийся проект дополнит резюме любого студента. По крайней мере для GameDev».

И что дальше?

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

Хочешь быть в курсе о ФИИТ и стать его частью, вступай в группу ВК и подписывайся на Инстаграм, а подать документы на поступление можно в личном кабинете УрФУ.

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

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

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

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

До старта проекта

Первый месяц — это погружение в теорию управления проектами. Мы выделили 3 занятия по 2 пары, чтобы разобраться с тем, как можно собрать команду, как планировать работу, какие есть способы управлять процессом. Занятия — не только голая теория, но и интересные практики с элементами фана.

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

Следующий этап работы — планирование и распределение задач.

На курсе мы предлагаем студентам использовать для этого Scrum. Попробую объяснить на примере, что это такое. Пришел к вам заказчик и сказал: сделай приложение, чтобы было круто и удобно. Что значит «круто и удобно» — неясно, причем часто не ясно и самому заказчику. Но вместо того, чтобы бесконечно и мучительно уточнять у заказчика все детали, нужно договориться о простом первом шаге, реализовать его как можно быстрее и минимальными усилиями, показать будущим пользователям и заказчику и отталкиваться уже от их реакции.

Как раз такой подход формализует Scrum. Мы выбрали его как самый легкий для входа и подходящий для студенческих проектов. С его принципами мы знакомили ребят на примере... строительства города (на фото) или туристического острова из Lego! :)

Lego это же так просто, да? Сложности начинаются, когда у вас есть заказчик с какими-то не всегда явными желаниями и ожиданиями. «Погодите, вы построили детский сад рядом с вулканом? Нет-нет-нет, безопасность детей — наш первый приоритет! Переделывайте!» Ребятам предлагается строить из Lego с помощью гибкой методологии, с итерациями, командным планированием, демонстрацией промежуточных этапов заказчику. «Вот, теперь отличный вулкан! А как все-таки туристы будут подходить к его жерлу? В смысле, «никак»? Кому нужен такой вулкан?!» Отличный и весёлый способ быстро и интенсивно прочувствовать смысл итеративной разработки. «Ого, это что, большая статуя пирата на пляже? Прекрасно! Очень нравится!».

Проект

Итак, собрали команду и научились планировать, пора работать! Самое время рассказать про задачу, которая стояла перед командами. Это был не совсем программный проект в обычном понимании этого слова. Это было соревнование.

Мы подготовили командный турнир по особенным правилам, в котором каждой команде нужно решить несколько сотен однотипных задач. Делать это можно вручную, но правильнее, конечно автоматизировать решение: получить с сервера входные данные задачи, вычислить ответ и отправить обратно на сервер до тех пор пока не истечёт таймаут. Чем больше типов задач умеет решать программа, тем больше баллов можно заработать и тем выше место в рейтинге.

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

Поэтому мы спроектировали правила нашего соревнования с нуля так, чтобы промышленные практики работы в команде оказались в нём максимально востребованными.

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

Итак команда получила с сервера несколько задач одного типа, поняла как автоматизировать решение таких задач, написала код решателя, запустила его и... в середине работы обнаруживает, что задача усложнилась и решатель больше не справляется. Пора срочно разбираться, ставить заплатку в коде или и вовсе всё переделывать. Так мы эмулировали «баги в продакшене» из реальной жизни :)

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

Сегодня большинство реальных проектов не обходится без git-репозитория. Система хранит историю правок исходного кода и позволяет команде с комфортом совместно работать над проектом, редактируя одни и те же файлы. В курсе за 4 пары студенты доходят от использования базовых команд до самых сложных. Упор делается на принципы работы, а не на зазубривание синтаксиса. И все это на практике: 10 минут слушаем преподавателя и тут же пробуем на собственном компьютере. И все это перед очередной итерацией соревнования.

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

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

Был и ещё один эффект от командного соревнования. Студенты узнали, чего можно ожидать друг от друга и заработали свою первую репутацию. Это пригодится им в следующих курсах, где снова потребуется формировать команды и делать проекты.

Итог

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

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

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

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

А если вы выбираете себе ВУЗ прямо сейчас, то обратите внимание на нашу программу ФИИТ УрФУ. Подать документы на поступление можно в личном кабинете УрФУ.

TL;DR: В следующую пятницу, 17 июля, стартует ICFP Programming Contest — ежегодное открытое онлайн-соревнование, придуманное функциональными программистами. По духу это развлекательный 72-часовой марафон с неожиданными задачами и сложно передаваемыми ощущениями от участия (о них пишут длинные статьи). Если не пробовали, обязательно участвуйте в этом году. Зарегистрируйтесь на сайте, подпишитесь на твиттер.

В отличие от других соревнований, для участия в ICFP Contest собирают команды, причем любого размера. В 2019 году были команды от 1 до 12 человек, а в медианной команде было три человека. За 72 часа нужно решить всего одну задачу — но всегда неожиданную, сложную и многогранную.

Например, в 2018 году нужно было оптимизировать 3D-печать с помощью наноботов. Вот впечатляющая визуализация решателя таких задач от команды WILD BASHKORD MAGES (Ripatti, LinesPrower и др.):

Год назад мы писали про планы сделать новую образовательную программу в УрФУ для разработчиков. В июне студенты направления ФИИТ закончат первый курс. Понемногу будем рассказывать о наших успехах.

Напомню, мы старались все курсы, даже фундаментальные, приземлить на прикладные задачи, которые требуются разработчикам. В том числе мы добавляли новые курсы в тех областях, где их не хватало. Сегодня расскажем про один из таких новых курсов — «Основы UX и UI» или по-другому «Основы дизайна».

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

Словарик

1. UX (User Experience, «опыт пользователя») — то, какой опыт и впечатление получает пользователь от работы с вашим интерфейсом. Удается ли ему достичь цели и насколько просто или сложно это сделать.
2. UI (User Interface, «пользовательский интерфейс») — то, как выглядит интерфейс и то, какие физические характеристики он приобретает: какого цвета продукт, удобно ли человеку попадать пальцем в кнопочки, читабельный ли текст и т.д.
3. UX/UI дизайн — методы повышения удобства и красоты интерфейсов.
4. Юзабилити-тестирование — исследование, позволяющее понять, насколько интерфейс удобен в применении.
5. Верстка — кроме того, что это привычная всем HTML-верстка, это еще и в целом расположение текста и элементов интерфейса на экране.
6. Инфостиль — стиль текстов, в которых акцент делают на понятности, дружелюбности и лаконичности. Термин придумал Максим Ильяхов, он же его популяризует.
7. Figma — графический редактор и онлайн-среда для совместной работы над проектом (это как гуглдок для дизайнеров).

Что за курс?

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

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

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

Примеры заданий

В теме «Композиция» студенты улучшали интерфейс оплаты заказа на портале toy4i.ru:

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

И вот примерно такой фидбек получали наши первокурсники:

«Классно, что студент явно обозначил этапы — сделал цифры крупными и яркими. Сразу видно, что есть 3 шага: заполни свои данные, выбери способ доставки и оплаты. Это считывается гораздо быстрее, чем в исходном варианте, и человек на такой форме сориентируется гораздо быстрее». Ксения Ильиных, преподаватель курса.

«Если придираться, то очень много цветов, которые визуально шумят. Адрес стоило подвинуть ближе к блоку «Личные данные», сейчас он будто отвалился. Возможно, если выровнять все блоки по левому краю, то цифры можно будет убрать — человек при скролле и так поймёт что за чем следует. Элементы в блоках разного размера, надо привести к одному, будет выглядеть аккуратнее». Андрей Пушин, преподаватель курса.

Похожее задание было в теме «Удобный интерфейс»: на основе полученной теории ребята переделали интерфейс одного запрещенного сайта.

Было:

Работа одного из студентов:

И опять дадим слово нашим преподавателям:

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

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

А в теме «Типографика» студенты делали лонгрид на основе страницы из Википедии. Вот что получилось:

«Студентка хорошо поработала с текстом: разбила его на абзацы, оформила цитаты и сделала крупные заголовки. Еще очень круто, что она ограничила ширину колонки — текст удобно и приятно читать. Из того, что можно улучшить: я бы сделала заголовки полужирным начертанием, это сделает их более контрастными. Когда мы просматриваем статью, то жирные акцентные надписи выделяются гораздо быстрее — человек зацепится взглядом, заинтересуется и будет замотивирован прочитать статью целиком». Ксения Ильиных

Атмосфера

Дизайнеры Контура делают занятия неформальными, больше похожими на диалог. С приходом онлайн-пар появился простор для фантазии: теперь можно провести занятие с акулой из Икеи или поставить смешной фон в Zoom :)

Некоторые студенты на последнюю пару в zoom пришли нарядными :)

А зачем программистам дизайн?

Обычно на айтишных направлениях не учат дизайну. Не учили и у нас. Мы считаем, что это неправильно. Хороший разработчик (а мы хотим выпускать только хороших разработчиков) должен понимать, что и как делают его коллеги в команде разработки. После курса студенты смогут общаться с продуктовыми дизайнерами на одном языке, самостоятельно проектировать минимальные удобные интерфейсы и делать верстку сайта. Еще мы хотим, чтобы студенты начали развивать свой вкус и насмотренность в дизайне как можно раньше. Поэтому мы ввели курс «Основы UX и UI» прямо на первом году обучения.

Нам важно объяснить ребятам, что дизайнер — это не «я художник, я так вижу», это настоящий специалист, который использует исследования и накопленный опыт, чтобы сделать продукт не только красивым, стильным и привлекательным, но и функциональным и удобным в использовании.

Что думают о курсе студенты?

Миша Бараковский

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

Марго Хрушкова

— Преподаватели очень доходчиво объясняют материал и всегда готовы помочь. Мне очень близок дизайн, я бы хотела заниматься им в будущем, поэтому была рада появлению такого курса.

Гриша Айдарцян

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

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

Что дальше?

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

Но и в этом учебном году было много интересных изменений. Сделали практики по программированию в курсе Алгебры (где еще вы такое видели?), провели курс по Основам проектной деятельности, а также первые защиты проектов с настоящим жюри из ИТ-компаний (ага, прямо на первом курсе).

Постараемся рассказать о самых интересных изменениях в следующих постах. Stay tuned.

А если вы прямо сейчас выбираете, куда поступать — подписывайтесь на страницу ФИИТ УрФУ в ВК, там мы публикуем больше разных подробностей мелкими порциями.

Привет, я — Павел Егоров, 13 лет пишу промышленный код, 10 лет веду курсы и школы по программированию, 5 лет развиваю онлайн платформу для обучения программистов, 3 года учу учить — руковожу отделом обучения разработчиков в компании СКБ Контур. А теперь я ещё и руководитель образовательной программы.

О чём речь?

Образовательные программы СКБ Контур 10 лет делают и поддерживают разные движухи вокруг ИТ-образования: от спортивного программирования (в частности, ICPC World Finals 2014) и CTF до собственных курсов и MOOC-площадки. Если кому интересно — тут много подробностей.

Много лет мы постепенно улучшали ИТ-образование в бакалавриате УрФУ, но у сторонней компании для этого не так много возможностей. А в прошлом году внезапно появилась возможность «сразу всё сделать правильно»: в очередной раз обсудив нашу давнюю мечту «сделать свой факультет» с директором СКБ Контур и ректоратом мы получили поддержку по всем фронтам. В итоге взяли под своё крыло направление подготовки Фундаментальная информатика и информационные технологии (ФИИТ) на бывшем Матмехе УрФУ.

Концепт у нас довольно простой: принять лучших студентов и уделить им столько внимания, сколько есть не во всех топовых столичных вузах. Через несколько недель на ФИИТ начинается набор, а с сентября первые 50 человек начнут учиться по-новому. Как именно — расскажу в статье